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Generating Solid Models From Topographical Data 

Topographical data are converted into forms useable by rapid-prototyping machines. 

Goddard Space Flight Center, Greenbelt, Maryland 


A method of generating solid models of 
terrain involves the conversion of topo- 
graphical data into a form useable by a 
rapid-prototyping (RP) machine. The 
method was developed to enable the use 
of the RP machine to make solid models 
of Martian terrain from Mars Orbiter 
laser-altimeter topographical data. The 
method is equally applicable to the gener- 
ation of models of the terrains of other as- 
tronomical bodies, including other plan- 
ets, asteroids, and Earth. 

Topographical data describe a terrain 
in terms of a set of three-dimensional 
coordinates [e.g., Cartesian (x,y,z) or 
polar (latitude, longitude, radius) coor- 
dinates] of points or nodes on the ter- 
rain surface. The input data for the RP 
machines are required to provide a 
three-dimensional description, not of a 


single surface, but of a volume — in this 
case, a ground volume that underlies 
the terrain surface. The description is 
required to be in the form of triangular 
elements that connect the nodes of all 
the surfaces and that completely bound 
the volume, with no open areas, no 
overlap of triangles, and no extraneous 
geometric elements. 

The software used in the present 
model-generation method was written 
in IDL — an advanced programming 
language that affords a number of 
tools, including subroutines that trian- 
gularize surfaces. The software creates 
a volume from the topographical sur- 
face data by adding sides to the edges of 
the terrain surface and joining the sides 
with a bottom surface. Each of the sides 
is triangularized by use of IDL subrou- 


tines, and then the software searches 
for extraneous elements and removes 
them. 

Topographical data are usually pre- 
sented in a grid corresponding to polar 
coordinates, so that a model generated 
from such data is equivalent to a topo- 
graphical map in Mercator projection. 
However an RP machine is fully capable 
of including the curvature of a planetary 
body in a model that it makes. There- 
fore, the software also offers a capability 
to transform the topographical data to a 
projection onto a surface having a curva- 
ture corresponding to that of the surface 
of the modeled planet. 

This work was done by John W. Keller of 
Goddard Space Flight Center. Further in- 
formation is contained in a TSP (see page 1 ). 
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Computationally Lightweight Air-Traffic-Control Simulation 

This algorithm simulates ATC functions for a busy airport. 

NASA’s Jet Propulsion Laboratory, Pasadena, California 


An algorithm for computationally 
lightweight simulation of automated air- 
traffic control (ATC) at a busy airport 
has been derived. The algorithm is ex- 
pected to serve as the basis for develop- 
ment of software that would be incorpo- 
rated into flight-simulator software, the 
ATC component of which is not yet ca- 
pable of handling realistic airport loads. 
Software based on this algorithm could 
also be incorporated into other com- 
puter programs that simulate a variety of 
scenarios for purposes of training or 
amusement. 

The ATC simulation problem that 
the algorithm is meant to solve can be 
summarized as follows: ATC is respon- 
sible for all aircraft that enter an arbi- 
trarily specified hemisphere, denoted 
the flight-simulator bubble, that is cen- 
tered at the airport. ATC must guide all 
the aircraft to safe landings in a se- 
quence that is as fair as possible under 
the circumstances. Information about 
the airport that is taken into account 


includes the lengths, directions, and lo- 
cations of end points of runways. Infor- 
mation about each aircraft that is taken 
into account includes the current 
three-dimensional position and veloc- 
ity, maximum and minimum speeds, 
and mathematical relationships among 
turning times and the starting and end- 
ing points of turns between specified 
headings. The solution generated by 
the algorithm must be a set of instruc- 
tions to the aircraft that enable all air- 
craft to land without violating any con- 
straints. 

The algorithm consists of four compo- 
nents denoted the controller, the plan, 
the vector generator, and the constraint 
verifier. The controller is event-driven 
and relatively simple: It responds to any 
of three events, as follows: 

1. An aircraft enters the bubble. The 
controller tries all vector options in a 
shortest-path-first order, checking 
each by use of the constraint verifier. 
When a solution is found, the con- 


troller issues instructions to the ap- 
propriate pilots. 

2. An aircraft leaves the bubble. The 
controller removes the aircraft from 
the plan. 

3. An aircraft changes location as pre- 
scribed by the plan. The controller 
causes the plan to be updated with the 
new location and time of arrival of the 
aircraft at the location. If necessary, it 
gives instructions to the appropriate 
pilot. 

Thus, the controller is the input/ output 
interface for the ATC. 

The plan is a data structure that is 
used to verify current and hypothetical 
routing for each aircraft. The plan con- 
sists of a simple temporal network 
(STN) augmented by labeling of time 
points with identities of aircraft and of 
other time points with which overlaps 
must be prevented. The approach fol- 
lowed by an aircraft is represented as a 
directed path in the STN. Inasmuch as 
each aircraft has its own unique path, 
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the overlap labels are used to enforce 
the fundamental constraint that no two 
aircraft may be in the same place at the 
same time. If two time points overlap in 
space, then it is necessary to ensure that 
they do not overlap in time. This is done 
by introducing temporal constraints. 
Operations on the plan include inser- 
tion of an aircraft, deletion of an air- 
craft, and updating of the position and 
time of an aircraft. An aircraft is in- 
serted into the plan by inserting its ap- 
proach. 

The approach generator generates a 
series of time points and temporal con- 
straints that represent a hypothetical ap- 
proach for an aircraft. It also generates 
the information for the overlaps for each 
time point of the plan. The approach 


generator includes a vector generator 
that iterates over options from most pre- 
ferred (a full-procedure approach) to 
least preferred (one or more turns in a 
holding pattern, ending in a direct ap- 
proach). Once a vector is generated, it 
must be verified as described in the next 
paragraph. If verified, it is incorporated 
into the plan. 

The constraint verifier checks a plan 
and introduces temporal constraints 
where necessary to maintain veracity. 
The constraint verifier identifies time 
points that lack temporal ordering be- 
tween themselves and members of their 
overlap set. It then incrementally inserts 
ordering constraints and verifies that 
each constraint is possible using tempo- 
ral propagation. It can preferentially 


schedule new points either before or 
after pre-existing points, according to 
the preferences of the designers of the 
ATC system. Once a verified plan is 
found, the verifier returns “true.” If a 
verified plan cannot be found, the veri- 
fier returns “false” and removes any ex- 
traneous temporal constraints it in- 
serted. 

This work was done by Russell Knight of 
Caltech for NASA’s Jet Propulsion Labo- 
ratory. Further information is contained in 
a TSP (see page 1). 

The software used in this innovation is 
available for commercial licensing. Please 
contact Karina Edmonds of the California In- 
stitute of Technology at (818) 393-2827. 
Refer to NPO-40445. 
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